TDL003 | Breaking Barriers: IPv6 Adoption and DNS Transformation with Tommy Jensen
Summary
This episode of the Defender’s Log features special guest Tommy Jensen, an internet technologist specializing in IPv6, Zero Trust, and standards. Jensen’s career path, from an AppleCare contractor to a key figure in advancing internet technologies, is explored.
The discussion highlights the critical importance and challenges of migrating to IPv6 and the necessity of overcoming legacy systems in enterprise networks. Jensen offers insights into his focus on DNS and Zero Trust, underscoring the delicate balance between privacy and security.
The episode also delves into the advantages of encrypted DNS, the disadvantages of TLS termination, and their broader implications for the future of the internet. Jensen concludes by emphasizing the profound role of the internet in connecting and fostering understanding among diverse cultures and circumstances.
Breaking Barriers: IPv6 Adoption and DNS Transformation with Tommy Jensen | Defender's Log Podcast
TL;DR
- Prefix-based Thinking: Emphasizes thinking in prefixes rather than individual addresses for better management and security.
- DNS over HTTPS (DoH): Highlights work on DoH and its political landscape, stressing the need for end-to-end security and privacy.
- Zero Trust DNS: Both agree on the benefits of “zero trust DNS” in enhancing security by verifying every connection.
- TLS Termination Criticism: Strongly criticizes pervasive TLS termination in enterprise environments due to its privacy implications and security risks, advocating for its reduction.
- Internet’s Health: Concludes with a broader discussion on the health of the Internet, urging for unity and a focus on human connection and rights, rather than political fragmentation or commercial interests, as the Internet’s primary purpose.
Links
View it on YouTube: https://youtu.be/eoocqJhIrmc
Listen to the episode on your favourite podcast platform:
Spotify
https://open.spotify.com/episode/1AGNE2NB0Gtb0jyGgvZePk?si=4zxWDoyJQiWRxZbcamNMTQ
Amazon Music
https://a.co/d/dllrGs5
ADAMnetworks
https://adamnet.works
Full Transcript
Chapter 1: Introduction to The Defender’s Log
Deep in the digital shadows, where threats hide behind any random byte, a fearless crew of cybersecurity warriors guards the line between chaos and order. Their epic battles, rarely spoken of until today. Welcome to The Defender’s Log, where we crack open the secrets of top security chiefs, CISOs, and architects who faced the abyss and won. Here’s your host, David Redekop.
Well, hello everybody, and welcome to episode number three of The Defender’s Log, where I really enjoy speaking to people that are real, that live in the defender space as it, uh, relates to the Internet and, uh, network technologies. And today, I have a special guest, um, by the name of Tommy Jensen. He’s an Internet technologist. And Tommy, if I had to summarize you into three categories, I would say you’re IPv6, you are zero trust, and you are a standards-based guy. All things that lead to a better future for the next generation and usage of the Internet. Did I summarize it well?
Tommy: I do like that. I think, uh, the community would be sad to not hear DNS in the list, but otherwise, good.
David: That’s my bad. We both live and breathe DNS as it relates to zero trust, so yes, I just thank you for, uh, for completing that. So I’m really glad that you could make it today, Tommy. I’ve been looking forward to reconnecting with you. Um, we recently, um, saw each other in, uh, Madrid at my very first Internet Engineering Task Force, the IETF. And, uh, what a pleasure. That’s a long week, but, uh, you found a way to really make it last. What did you do to make it really fun?
Tommy: Oh, goodness. Uh, the IETF is itself fun all the time. Busy and sometimes very long days, but that is the fun. I usually spend a lot of my time working in the DNS working groups as well as the, uh, V6 Ops working group, but more recently, I’ve started as a co-chair of the Digital Emblems group, which took up a decent amount of time that I really encourage everyone to look into.
David: My first experience working with you and John Todd—by the way, he was on the previous episode of The Defender’s Log, uh, with me—and, uh, we really enjoyed the exercise of rustling through the process of creating or proposing or thinking through a new standard. So, I owe you thanks for inviting me into that and for working with, uh, John and me on that together.
Chapter 2: The Unlikely Path to Technology
David: Tommy, I’m really interested in having not only our team at Atom Networks but our audience as a whole get to know you a little bit. Who’s, uh, who’s Tommy? How did you come about to get in the space of technology and then in a defensive kind of posture to begin with? Like, what was an early childhood tendency or experience that kind of led you down this path?
Tommy: So to be honest, uh, there was nothing in childhood at all. I fully intended to get into civil engineering, which is where my undergrad started. I didn’t really get into computing until I dropped out of college and then got a job working at a, uh, contractor for AppleCare, where I learned to use Apple platforms instead of Windows and start using actual scripting. I was like, “Whoa, like, people do this for a living.” And when I did get around to going back to university, I went and did computer science after a brief stint in linguistics, just because it paid.
David: Was that the interest, or was there another aspect of interest that just happened to be amplified because this is actually a career choice because it gets paid?
Tommy: Honestly, at first, it was just fun. I had never felt—I kind of caught that early computer science, early Internet bug, you know, of like, “Wow, this is just so cool to be able to interact with a computer this way, to actually be able to automate and do things.” Not ashamed to admit it, the money, of course, like, the field is good, right? My parents were certainly happy to see me move out of linguistics into computer science for that reason. But I just find it fascinating.
Chapter 3: Community and the Evolution of the Internet
David: Never ceases to amaze me how fast technology has advanced. Every once in a while, when you, uh, hear an old clip or watch an old clip with the dial-up modem screeching, you can always tell the guys that can make the differentiation between 28.8 kilobits per second versus, “That’s 33.6.” That’s like a major improvement. Was that you?
Tommy: No. I used dial-up growing up. I know what it feels like to get yelled at for hogging the phone line, but I could not tell the difference in the line rates by audio.
David: You made me think that you might have because of the linguistics approach, because it is about the tonality. And then I’ve also seen clips where, uh, isn’t there some, uh, movie with a clip where an astronaut is in space trying to put together a serial 9600 baud, uh, modem dial script or something like that? It might come to me, but, uh, somebody will tell me in the comments at some point about what the reference was. And, uh, nowadays, my wife and I have children, and, uh, if I ever bring up any of these things, it’s just like a blank stare. Like, there’s no interest about what the building blocks were that we’ve left behind.
Tommy: That’s half the fun of the IETF is getting together with peers who don’t get bored talking about stuff like this.
David: And when you, uh, first told me that the group of a thousand people is going to seem small by the end of the week, I had no idea how, uh, true that was until, uh, until it was the end of the week. And, uh, what do you know? Made some, uh, new friends that we’ve, uh, connected, including some fellow Canadians that I’ve had breakfast with since then. I happen to be in Ottawa, so connected with, uh, a prolific RFC author that lives there, and, uh, we had, uh, we had a nice breakfast that exceeded expectations. And, uh, so yeah, those moments are really—I don’t know if you find the same, but I actually find them encouraging, rejuvenating, being part of a community that is truly focused on doing the right thing for the right reason, where just, um, the monetary compensation is not a driver at all, but rather thinking about how do the maximum number of people and organizations and future generations, uh, benefit from this. And when I saw your focus, I saw that, uh, character trait in you as well, Tommy.
Tommy: Well, I appreciate that. I would like to think that what I do contributes to a greater good. Every year I am in this industry, I learn more and more to the point that I look back at the prior and think, “Oof, I could have done this better. I could have, could have, could have,” right? And I try not to focus on that, but yeah, I would like to think that I’m contributing to a better Internet.
Chapter 4: The Case for IPv6
David: Yeah, for sure. Talk to me about IPv6. Uh, Tommy, I know you’re a big proponent of it, and you and I in some ways live in opposite extremes in that space, where we work with a lot of SMB/SME clients where the whole of the network is still, you know, private class IPv4, you know, your dreaded RFC 1918. I know that makes you cringe, and you would rather be a purist and say, “Look, whatever it takes, just move everything to IPv6.” Other than the big picture that it eliminates, you know, most of NAT, it makes everything more predictable. Tell our audience what some of your thinking is, why that drive forward is important.
Tommy: To kick that off, I will say that one of the many things that I’ve learned year over year, as I was alluding to earlier, is the difference between the ideal and the ideal that works in practice. I don’t know, you know, the phrase, “The best diet is the one that you’ll actually keep,” applies to networking, right? Because ideally, we would wake up tomorrow, everyone would switch to IPv6 wholesale. There’d be no need for transition of anything, right? Because a lot of the complication people associate with doing IPv6 is really about trying to keep dual-stack working and transitioning to IPv6, but that’s not how the real world works. And so everything that I say, I say knowing that it’s in the context of what the goal should be, not shaming anyone for not being there yet, because there are lots of good reasons why this takes lots of time, having worked with many customers on this.
So, you know, the obvious answer, right? The larger address space is something that I think people—there’s a lot to that, um, because it’s not just about it being larger. You know, people will talk to me about NAT and say, “Look, we’re using 1918 space. We have NAT, so we don’t really run out of addresses, right? We may use the entire /16, uh, /8 in the 10-dot, but I can use it multiple times. What’s the problem?” By the way, seriously, using the entire 10-dot, I’ve seen it. Um, it’s crazy.
David: You and I have been through airports that do that. Like Vancouver International Airport Wi-Fi. If your VPN terminates and also assigns you a 10-dot, like there’s a perfect use case for “just go IPv6” because you’re going to have trouble with most of your VPNs, right?
Tommy: The big one that I’ve seen the most, though, in enterprise is mergers. So everyone thinks about their network today, and one of the many strengths of IPv6 is when you try to envision what happens to your network tomorrow. So when you try to merge sites that are already using their own IPv4 space—and yes, you know, the /8, the /16, those aren’t big in IPv4, they’re really not—and when you go to merge them and unrelated CIS admins have overlapped in ranges, doing that reassignment can often be really tricky. Because we can say that IP addresses are supposed to be ephemeral, that they’re a routing ID that no one at higher levels should take into account. We all know that’s not true. There are lots of hidden assumptions made, and when you have to go merge those, call me back and explain to me how there’s no solution needed for the NATing situation, right?
Um, to me, that’s a really big one because company mergers are an easy example, but honestly, there are lots of less dramatic examples of, “Well, now I want these networks to be accessible, um, without a choke point.” Okay, in IPv6, that’s trivial, right? In fact, it would be easier to just start off that way because you do have a flat network with the global Internet usually. Um, NAT makes things complicated. NAT makes things state-maintaining at a border that you have to maintain, and we’ve kind of taken that cost for granted. But why, you know, if you don’t have to, why should you? That’s a big one I think that I don’t hear people bring up quite as much as the more obvious “just addressing what you already have.”
Chapter 5: Overcoming IPv6 Adoption Hurdles
David: No, you make some very good points there, and I could see that being the case with organizations that are potentially ever going to merge, but it seems like the reality is that most—what is the line that I recently started to use that I also heard from someone? “We have built our networking like we have built our cities: slowly, without a plan, on top of ruins.” And so the net result is we’ve got a plethora of networks and legacy gateways out there. In reality, the 70 million-odd small businesses that exist in the world today, I would guess that less than 1% of them would be IPv6 enabled. And you and I live in geographies and jurisdictions where IP availability isn’t a problem yet. But in a good chunk of the world, it’s not even available. You can’t even buy it, you know? Like even, uh, Starlink for a very short time period offered, um, a public IPv4, and then that just became part of their unaffordable price plan for most small businesses, uh, at some point. And so that’s the reality. The price just keeps on going up because it’s—I hate to equate it to Bitcoin, because you always have to introduce Bitcoin in every conversation, but there is a fixed supply, people, of IPv4, and that’s why the value will always go up.
Tommy: Yeah, that’s definitely true. There’s a global inclusion aspect to this, and you typically think of, you know, human rights impacts, global inclusivity as belonging to much higher layers. We talk about like the web, but a migration to a large enough address space that everyone can afford their own subnet is completely valid.
David: So let’s talk very briefly about the flip side of that in terms of availability. I know that the major Internet service providers in the US, where you’re from, and Canada, where I’m at, it’s not an issue. Uh, we can get IPv6 address space, but then there’s a lot of national providers that don’t offer IPv6 yet. In fact, I have a backup ISP, and I asked for an IPv6 connection. They said, “No, we don’t offer that at this time.” This is the year 2025, for a brand that you would recognize. And I don’t want to use this as a shaming, um, channel or anything like that, but it really came to my surprise that that was the case when I turn on my Rogers, uh, mobile phone and I only get an IPv6. So, we have the aspect of, “Okay, universal adoption would be a good thing,” but we still have roadblocks from it even being possible.
Um, and then there’s also the aspect of IPv6 where address space is so large that in the absence of zero trust, where you and I have been working hard at, it means that the ability to uniquely spearfish is amplified to the advantage of the adversary. So when you think about if you’re going to send someone a smishing link, that IP address will probably be blocklisted very quickly by some leading threat intel. So you’ve got a very limited lifespan, and that’s why phishing links are almost always DNS-based. But once you can go by an IP address and it doesn’t cost you anything and you can just drop it and get a new one, like, I have not seen that trend pick up yet. But the theoretical possibility of how many more IP addresses there are to uniquely spearfish every human on Earth is kind of frightening.
Tommy: So this is an area where there’s another advantage to IPv6, or rather, a lack of disadvantage, because it is easy to think about IPv6 the same way we do IPv4 and talk about addresses. In truth, we should really be talking about prefixes. So, for example, let’s say that my ISP does happen to offer IPv6. Not all that I have had in the last couple of years do, but currently, uh, mine does; they give me a /56 for my house. Um, I actually just set it up recently, and I don’t remember what they gave me. I’ll have to look. If I can generate tons of addresses, unique ones, millions, billions, and pepper the Internet, whatever. But in truth, there’s only one prefix, right? And yeah, there’s some ambiguity there, right? Because you don’t really know the boundary of a given prefix for a different actor. But when it comes to, say, let’s say you’re using JA4 fingerprinting and you start seeing bad actors as part of a DDoS, looking for the longest common prefixes is a great way to do ad hoc responses rather than try to uniquely log all these IP addresses.
Another example of this is in the old world, using the legacy IP protocol, you would do security logging based on the addresses you handed out via DHCP. Now, you can try to do that also with DHCPv6, but the truth is there’s a lot of good reasons why you should not be handing out /128s only to your devices, chief among them being 464XLAT, enabling your IPv4 apps to communicate over an IPv6-only network, right? You’re going to want to hand out prefixes, use DHCP-PD. The concerns that I have heard from customers over and over again is, “Well, that makes my logs too large.” And that’s something that I have a beef with given vendors because they’re making that arbitrarily difficult. You shouldn’t be tracking addresses. Hand out /64s per device and then track the /64 prefix, and you’re back to doing a linear amount. It’s just we think in prefixes, not in addresses.
Chapter 6: The Politics and Passion of DNS
David: That’s really wise, Tommy, and I have not been working enough in this space, uh, myself at the actual application level for that to have come up as much as for you. So thank you for sharing. I love doing this because I learn every single time I am with you. So thank you for that. Let’s switch to DNS for a minute, if that’s okay.
Tommy: Of course.
David: What made you focus on DNS when it came to zero trust?
Tommy: My entry into DNS as a working professional was in 2019. I found a new job within Microsoft from what I had been doing previously and my venture into Windows core networking. And my very first assignment was, “Here’s the DNS client. You should do stuff with it.” And I was told at the time that DNS was a relatively stable, retired, legacy protocol and there wouldn’t be much to do. And looking back, that’s incredibly laughable because it’s all but, right? And the first thing that I worked on was DNS over HTTPS. And at that time, there had been an association of UK ISPs that had nominated Mozilla for Internet Villain of the Year, uh, for working with them, right? There were parties in the US that were pushing for DoH, DNS over HTTPS, to be classified as anti-competitive. Um, it was kind of wild, right? And there was a group trying to form in the IETF, uh, which is now a very calm working group called ADD—Applications Doing DNS, I think is where we started, but now it’s Adaptive DNS Discovery—that was where I started. And I was like, “Whoa, this is cool.”
And I quickly learned that I needed to both be a technologist, and like a deeply technical technologist, and a policy-aware one, because boy, is DNS political. So that was where I started, and it’s all been new adventures since in trying to figure out how do we provide end-to-end security and privacy, because they’re not opposed to one another. It requires breaking some legacy thinking, the same way that deploying IPv6 makes you think differently than deploying IPv4, but it’s totally worth it. And I realized there’s not enough being done to do it correctly that it just became a real passion area for me.
Chapter 7: Breaking the False Dichotomy of Security vs. Privacy
David: That’s a good solid foundation, and it’s almost like your timing of entering DNS could not have been better because you entered at the tail end of Do53’s, you know, ossified state, as it were, and, uh, right into, “Okay, it’s time to secure the last piece that is still causing us, you know, lack of privacy and, uh, sort of forced transparency where transparency isn’t needed,” right? Especially since the Edward Snowden days, we became aware of how much of the transit traffic gets scooped up, and it’s not always in our best interest that it gets scooped up. So those of us that are appreciating our civil liberties, we want to be able to, uh, preserve those as best as possible. So that was—I can see how that space just totally captivated you.
Um, my path was slightly different, and that was, uh, more about having it as a control plane, as Dr. Paul Vixie calls it. And then, of course, as soon as DoH came about, then it looked like, “Uh-oh, that control plane is now gone. It’s being circumvented,” which isn’t a concern for you and I anymore because of our focus on zero trust. I’m curious, was that something that you foresaw, that the zero trust DNS approach, or what we call “don’t talk to strangers,” was something that would be the answer to that? Or was the answer to that more of an unintended consequence?
Tommy: Not immediately, because in 2019, when I first entered the space, I was still very much learning, but fairly early on and long before, uh, we at Microsoft, while I was still working there, had announced it. Because I’m glad you brought up—you mentioned Edward Snowden in passing. That was a big—2013 was a big year in terms of Internet technologists and learning how we need to influence the industry, because that was the same year the justice system did what it did to Aaron Swartz. That was a very formative time, and I saw working on DNS as an opportunity because HTTPS is pretty prolific and even then was pretty wide, and so DNS was the next big leakage of private information on the web. So, you know, DoH was important. Yes, DoT already existed, but DoH was important because it helped obfuscate the use of encrypted DNS.
For me, where I first started thinking about zero trust in the context of DNS was how you manage domain name-based anything in the presence of that, because I am fully a believer and supporter of the end-to-end principle. The Internet is for users. End-to-end encryption is a good thing. And yet, a lot of the security mechanisms used historically with domain names have been on the wire, right, by a third party to the communication. So in a world where we encrypt that rather than implement weaknesses like, uh, the approach with eTLS did to counter TLS 1.3, it was clear that we needed to make parties the peer. Like, if you wanted to do security things, you need to be the resolver, um, in one way or another. And then what do you do with that? Because as you said, IP addresses are cheap these days. Um, it’s easy to hide things. And everyone operates on domain names, right? Like very few things are identified by IP address anymore to human awareness. And so customers overwhelmingly do not want to say things like, “Sure, let’s keep track of 14,000 CIDRs and what they’re tied to. And I’ll update those once daily whenever each random vendor changes something.” What they want to do is use a well-known star.example for a given purpose because that won’t change, or will very infrequently change.
And so it was an intersection of things, really. But at the core, and what has always been at the core my entire time in networking protocols, is how do we break this false dichotomy of security versus privacy? And the zero trust approach isn’t perfect but helps achieve that. You don’t need to go breaking encryption to do name-based segmentation by taking this approach, right? You don’t have to choose between security and introducing attack points wherever you’re terminating traffic in order to do what you need to do.
Chapter 8: The Reality of Zero Trust DNS Implementation
David: You did. And it’s your detailed, uh, responses that make you who you are, Tommy, because you take a technical problem and description and you bracket it with a proper beginning and a proper ending, right? Way too many of us in the tech space have, uh, some level of attention deficit, and it’s nice to see you, um, actually completing a thought all the way. So no, I definitely appreciate that. Let’s, uh, think forward through that process now. Because you and us both went through the same challenges that, “Okay, this whole approach of zero trust DNS, meaning that there is no IPv6 or IPv4 address that I can connect to unless it was first allowed and resolved by DNS,” that turned out to be not necessarily a new idea, but for the first time that it was actually implemented when we did it. And you did it independently, as far as I understand, right? Like I did not know of you, you did not know of us, and we focused on different areas. We did it at the gateway, and you did it at a Windows endpoint. How soon did you realize all the stuff that would be broken?
Tommy: Right away. Even at idea conception, as I started talking with people internally about, “I think this is where we need to be going for various reasons,” that was the very first feedback I got, is, “Do you have any idea how unworkable this is?” And that’s been a steady, regular source of feedback, is, “This is ludicrous, right? It’s never going to work at scale.” And the truth is, it will, but it is certainly breaking a lot of things that we used to do, um, and that we should be rethinking. I have decks and decks and decks of going through examples, which is why also, as documented by Microsoft in the preview disclosures, there is a way to configure CIDRs with specific intents to say, “This CIDR is required by this program,” so that it can be logged and segmented by a name the same way that you would as a domain name, but not as much as people think.
If anything, it’s kind of nice because it does break a lot of things. And turning the question around, do you have any idea what your endpoints and networks are doing, right? Uh, because it’s a lot. And when you implement, uh, “don’t talk to strangers” or ZT-DNS for the first time in enforcement mode, sunlight on all these shadows that you’re like, “Oh my goodness, what is this application? What is this endpoint?” is a good thing in the long run, even if it’s scary up front. But yeah, I very first prototyped, uh, ZT-DNS as a proof of concept as part of the planning process, and the very first version was definitely an eye-opener of like, “Huh, what is that component doing? Huh, why does this program do that?” Yeah, very eye-opening.
David: I have to tell you, um, my earliest experience was when Internet Explorer was still the dominant browser. To me, what was the most discouraging part of that was that IE had no consistency in honoring time-to-live. And one of the core principles of what we wanted to do was to collapse the outbound allow rule that had been created and then only leave it open for the period of time-to-live. When we did that, we broke even a regular website that did not have any JavaScript code referencing by IP, but because the browser, uh, was hanging on to the cache. Maybe it originated with good intent back in the day when caching as long and as often as possible was maybe a good strategy. But then when Chrome and Chromium-based browsers started to trend up very rapidly around that same time, we said, “Oh, there’s hope here. This might work as long as we minimize dependency on IE.” Uh, and so that was our first experience.
And then I have one other one, our most recent one. I don’t know if you’ve come across this one, but ever since, uh, what is the new, um, universal rich text, uh, message, uh, format that Google is, uh, happily facilitating?
Tommy: Rich text format. I mean, Markdown is my bread and butter.
David: RCS.
Tommy: Oh, sure. Sure. RCS. Yes.
David: Okay. So, turns out that RCS for the most part goes direct by IP. I’m like, “Come on. This is Google of all companies and the implementers of RCS that route it through Google servers. Please don’t do that.” And I don’t even know where to start. So we actually have to have a special treatment in terms of managing as we observe, uh, new rejections from similar IP space. Anyway, it’s that one has been the most difficult one. Other ones are quick and easy to observe. RCS differs for different networks, different mobile networks in different countries, which has become complicated because sometimes we only discover them as we get subscribers in those countries with those mobile carriers, and as we know, there’s thousands of them. So, that one has been the most complicated one. Do you have any other examples that you’ve been working on?
Tommy: I did not run into the RCS one in my time at Microsoft. So, I am sorry to hear that. That’s going to become more problematic, and RCS is a good thing. So definitely something that needs to be worked out. I too ran into the, “You know, TTLs are more of a suggestion than they are a guideline.” Yes. Problem, except I would say that that’s pretty ubiquitous now. So that was a place that I started also when writing the prototype was to say, “I’m just going to time-bound this because that’s proper zero trust, right? Don’t allow it forever. Um, time-bound access.” Boy, TTLs are useless for that and arguably inappropriate for that the more I thought about it and collaborated with people, but you do still need a time-bound. And so allowing the administrator to configure things makes sense for an additional reason, actually. Um, because a lot of websites use arbitrarily short TTLs because they’re paranoid about how quickly they’re going to change their IP mapping. Yeah. And I say paranoid, maybe I’m uneducated and they really do. I doubt it. When I would do experiments, I saw the exact same IP address all day. But the TTL is 30 seconds, and it’s like that’s really not helpful. It is what it is. Everyone, for performance reasons, caches everything for as long as it continues working, which, you know, I can’t blame them for that. What’s written in an RFC and what works in practice are very different. And it’s hard for me to point it at a vendor and be like, “You messed up,” when the truth is, you got to do what you got to do. So, it makes sense to have time bounds. We ran into the TTL problem and quickly abandoned it.
Chapter 9: The Trouble with TLS Termination
David: We talked about TLS termination and doing man-in-the-middle on the fly or a full-on proxy. What’s your big-picture philosophical perspective on, um, on that approach?
Tommy: Everyone I’ve ever worked with is laughing if they’re listening to this because they’re expecting me to froth at the mouth at this moment. In short, I really detest it as a practice. And I say that full well knowing that my previous employer and my future employer sell products that use it, and I have contributed to some. So when I say that, what I mean is it should be a goal for us to reduce its use to zero. And what I mean by—because TLS termination in the literal sense, somebody’s going to be doing it, right? Um, that’s not what I mean. What I mean is having TLS termination done by a party that isn’t privy to the private keys of the true destination, right? Because for example, uh, front door services, CDNs, right? These are parties that terminate TLS sometimes to then allow forwarding via other protocols or within other security boundaries’ content. I don’t have a problem with that. That’s a big part of how modern services work. And there is a trust relationship between the terminating party and the actual destination where either the private keys are shared or you do something like delegated credentials or star certificates. They have a legitimate right to terminate that traffic.
What I mean is the overgeneralized termination of traffic where the terminator is—that’s a funny way to put that—the party that’s terminating TLS is doing so for a large number of destinations that have no relationship with the one doing the terminating. That is something that we should be looking to reduce the usage of. And ZT-DNS, one of its big value props that I was happy to push, was it helps eliminate the need for that if you were terminating TLS simply to determine destination. Huge asterisk, because it isn’t exactly the same. You know, things like domain fronting, connection coalescing can lead to edge cases. Yes, listener, I am well aware of that. In broad strokes, it can be helpful. Right.
So my feelings on TLS termination, scoped to that use that I’ve described, are very negative because A) huge privacy implications, right? And I have heard many people in the industry say, “Well, in the enterprise space, that’s not applicable because it’s the enterprise’s data,” and that isn’t true. I’ve started a law degree, um, exactly to tease out the kind of nuance behind those assumptions. And the truth is, depending on the country you’re in, you actually have some pretty significant rights to privacy as an employee even if you’re on your employer’s, uh, endpoints and networks. So A, that’s not true. B, it’s actually a regression in security, right? It’s this false sense of security that says, “Now I can see everything.” And B.1, no, you can’t, because all that gives you is access to traffic that trusts the root store in which you installed your terminating certificate. Applications that bring their own TLS libraries that don’t respect your root store don’t care about that. Applications that do cert-pinning so that they check for intermediates because they know what certificate was supposed to have signed that—they’ll break too. And so then you end up programming these exceptions. Well, this vendor’s, you know, for example, Microsoft does not support TLS termination for a lot of their web services. And if you call them and say, “Hey, it’s not working,” they’ll say, “Bypass the proxy, hang up.” You’re not getting that. And B.2, you’ve created this beautiful, beautiful target which in zero trust, uh, is an absolute no-no, right? You have this high-blast-radius target that if I can compromise this one node, then I get access to data across many clients, across many, uh, client identities, across different destination properties in plain text. That’s ludicrous. Why would you create this high-value target? And you know, people say, “Well, because it’s in my data center,” as if that means that it’s not compromisable. And the truth is, everything’s compromisable. That’s kind of an underpinning of zero trust. And it’s just a matter of time. It’s when, not if.
David: So those are some reasons why I don’t like TLS termination. For those that, uh, I’m sending this video link to, now you know that I’m not the only one who’s been resisting or trying to eliminate it, or at the very least get it as close to an individualized area as possible when it’s necessary. I know that there are some places where for compliance reasons you need to have that. Okay. Well, then make it, like, you know, as close to the end-user as possible, that’s completely sovereign, that’s not available to a third party, not outside your network, right? Those kinds of things.
Tommy: Absolutely right, because zero trust is all about limiting attacker value out of a given avenue. So yes, having enclaves, as it were, where this is a point that terminates TLS for the following five properties that are all related, versus another tunnel that does it for these, is at least better. Doing so for client identities and having different certificates issued such that you don’t have one private key that rules them all would all be baby steps in the right direction. I just—that’s not what we see in practice, though, is it? We get the one cert, we get the one tunnel, everything goes through this one node, and I hate it.
David: Okay, Tommy, I do have, as I mentioned to you when we had a nice pizza outdoors in, uh, Madrid, that, uh, I have a draft blog article on this topic. So, I’m going to reach out to you about co-authoring some of those elements with you because we’re 100% on the same page.
Chapter 10: A Message for the Internet Community
David: Just switching gears for another, uh, last couple of minutes. Is there any key message? This is what our team wanted to know. What does Tommy want the world to know that we may not have addressed yet today?
Tommy: Given that kind of blank check, it would be to zoom out and talk about the health of the Internet, right? It’s all too often we assume to ourselves when we work in the industry that there’s this separation, that the whole, you know, “the Internet is for users,” “privacy,” “human rights” is distinct from what we do for work, which is we need to create these functional networks for enterprise and thereby create this dichotomy of, you know, people that are pro-enterprise stories and people that are pro-Internet for journalists and activists and the oppressed. And the truth is, we got to stop doing that because it isn’t, it isn’t true. It’s so easy when we work in the enterprise space and the commercial space to say that the two things are just separate, and they’re not.
You know, in 2025, we’re looking at more pressure to fragment the Internet than we’ve seen yet, right? I won’t, you know, let’s not go into naming countries and things. I don’t know, you know, what kind of tone you want to set here or get you into trouble, but that’s something that everyone should be concerned about. You know, as private citizens of various countries, having access to other people’s propaganda other than your own. Fill-in country name here. Being able to communicate with loved ones across the world who may not have the freedom to move around. Having access to information that lets you better your own life circumstances. It’s really easy and popular right now to focus on the huge negatives of the Internet right now. You know, misinformation, harmful content, and those things are completely valid concerns. Like, we do need to work on those things. I just, you know, if I could say anything to the world, it’s, “Please stop turning this into us versus them.” Like, we do have the one Internet, right?
And enterprises benefit when individual human rights are upheld, and individuals benefit when governments and enterprises are more secure. You know, these are the parties that hold things like, you know, national ID numbers and your banking information and other things that you really don’t want leaked, right? You know, doing the very boring stuff in diplomacy of talking to parties you don’t like working with and hearing out cases you don’t want to support to help figure out what that third path looks like. And sometimes just being able to more authoritatively say, “I’m not saying no because you’re on the other side. I’m saying no because I fully explored your use case and I explored your concerns both from the technical aspect and the social context in which they live.” Right? Because the Internet doesn’t live in a vacuum and still believe that this is the right path because… and be more articulate. And I know that’s super generalized, um, but I could rant about this for hours if we got specific. Encouraging people to think of the Internet in terms of humans rather than business cases or politics, you know, from any one given angle.
David: I don’t know where you stand politically, and I don’t know that you know where I stand politically. And here’s the most beautiful thing: it doesn’t matter because you and I can both feel respectful towards one another and do a deep dive to get at the truth that is based on merit. And, uh, once we get to that common agreement, then all politics loses its power because you’re operating from the same source of truth, because it’s only Truth if you both see the same thing, right?
Tommy: Yes. Which is why it’s so helpful to think in terms of security and privacy, because independent of what message one wants to communicate on the Internet, independent of, you know, what you consider to be sensitive, we should all be able to agree that we benefit from having control over our own data and being able to trust that other parties actually have some semblance of security when handling our data.
Chapter 11: The Future of a Connected Humanity
David: Well, last question. What are some aspects of the future of the Internet that you are excited about?
Tommy: Wow, I really do spend too much time thinking about the negative. My first reaction to that is what I have previously been excited about and have continued seeing is the ability to learn about other people’s situations. One of the things that I tell my mentees the most is that people come first. Right? We didn’t build the Internet to enable bots to talk to each other, setting aside AI agents for a future episode. Perhaps it exists to support humanity. And the Internet has given me the ability to do things like learn the languages of my colleagues and co-workers and be able to learn more about their cultures, understand what their life circumstances are, and what it means to be themselves versus just a cog in a given machine. It lets me be able to appreciate what other people do outside of technology, which I don’t spend as much time in, right? It lets me see what other people have to deal with, to suffer through.
Because it’s one thing to talk about, “Encrypted DNS is important because it enables privacy.” Great. How about, “Encrypted DNS is important because maybe in the US, my grandmother doesn’t know what it is, but in some countries, it’s something that’s spray-painted on multi-floor buildings. That means the difference between being able to speak with your child again or not, or getting executed for revealing that you’re of a given population demographic or not.” I wouldn’t know those things without the Internet. You know, my local communities don’t have any connection to that. And what has always excited me and continues to excite me about the Internet is the ability to connect different aspects of humanity and help remind each other and grow together as a single family, rather than segment ourselves into various local identities and finding ways to other each other.
David: Love it, Tommy. And that reminds me of many mentorship opportunities, mentee opportunities I had at a company I previously co-founded. CEO Charlie would say this regularly: “People are more important than things.” If the Internet is exciting to you because the future is going to showcase that, then I think that’s a good place to end it today. Thank you so much for your time. I know this is a special time in your season right now. So, I’m looking forward to staying connected, uh, with you on future projects and, uh, hope to see you at IETF 124.
Tommy: Oh, I will absolutely be there, and thank you for having me. You do great work, and I’m happy to be here.
David: Thanks, Tommy. Take care. Bye for now.
*The Defender’s Log requires more than a conversation. It takes action, research, and collective wisdom. If today’s episode resonated with you, we’d love to hear your insights. Join the conversation and help us shape the future together. We’ll be back with more stories, strategies, and real-world solutions that are making a difference for everyone. In the meantime, be sure to subscribe, rate, write a review, and share it with someone you think would benefit from it, too. Thanks for listening, and we’ll see you on the next episode.*IPv6 Adoption: The critical importance of IPv6 is discussed, advocating for its adoption to solve issues like address scarcity and network merging complexities often seen with IPv4.
1 post - 1 participant
The post TDL003 | Breaking Barriers: IPv6 Adoption and DNS Transformation with Tommy Jensen appeared first on Security Boulevard.
>>More